Skip to content

Detect Fossil repositories in cargo --fix#17085

Draft
geraldolsribeiro wants to merge 2 commits into
rust-lang:masterfrom
geraldolsribeiro:master
Draft

Detect Fossil repositories in cargo --fix#17085
geraldolsribeiro wants to merge 2 commits into
rust-lang:masterfrom
geraldolsribeiro:master

Conversation

@geraldolsribeiro

Copy link
Copy Markdown

What does this PR try to resolve?

Fix #12721

cargo --fix does not detect a Fossil checkout and aborts execution of --fix.

How to test and review this PR?

The current behaviour is to emit an error when inside a Fossil repository (not a git repo), like below:

cargo fix --bin "lazyfossil" -p lazyfossil
error: no VCS found for this package and `cargo fix` can potentially perform destructive changes;
if you'd like to suppress this error pass `--allow-no-vcs`

With this fix cargo performs as expected:

/home/geraldo/git/geraldolsribeiro/cargo/target/release/cargo fix --bin "lazyfossil" -p lazyfossil
   Compiling libc v0.2.186
   Compiling proc-macro2 v1.0.106
...
warning: `lazyfossil` (bin "lazyfossil") generated 2 warnings
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 5.05s

@rustbot rustbot added A-vcs Area: general VCS issues Command-new S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 8, 2026
@rustbot

rustbot commented Jun 8, 2026

Copy link
Copy Markdown
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @epage (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue
Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: @ehuss, @epage, @weihanglo
  • @ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
  • Random selection from ehuss, epage, weihanglo

@epage

epage commented Jun 8, 2026

Copy link
Copy Markdown
Contributor

Several high level notes:

  • This make changes to cargo new / cargo init without discussion which should at minimum be its own commit. Poss!by a new PR depending on the motivation
  • Our contrib guide asks for atomic commits
  • Our contrib guide asks for tests but none were added for cargo fix. Note that it asks for a specific commit structure for these that I go into more detail at https://epage.github.io/dev/pr-style/#c-test
  • Our contrib guide asks for Issues to be S-accebted before posting a PR. This is a S-needs-design, particularly because we are hesitant to commit to new or deeper integration with vcs's

Based on the above (particularly the last point), I'm moving this to a draft.

@epage epage marked this pull request as draft June 8, 2026 12:11
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-vcs Area: general VCS issues Command-new

Projects

None yet

Development

Successfully merging this pull request may close these issues.

cargo --fix does not recognise there's a VCS on a fossil project

3 participants